11章 変数名の力

全体的に直感的には分かっていることを改めて文章化してくれててスッキリする章だった。ここだけ読んでも参考になりそう。

この悪い例は養殖物だけど、そういうことだよねってやつ

ｘだったら読み解こう、となるけど違う意味で取れるような名前だともっとやっかい

11.1 良い名前を選択するために

https://gyazo.com/afc5cf6c2fbc39aca38071c3f2ce904d

https://gyazo.com/42d038ff1e158b2bcca31d11fbe6bddd

11.1.1 名前をつけるときに一番大切なことは

変数が表すものを完全かつ正確に説明するような名前をつけること

読みやすい変数たち

アメリカのオリンピックチームに所属する選手の数を表す変数

numberOfPeopleOnTheUsOlympicTeam

オリンピックスタジアムの座席数を表す変数

numberOfSeatsInTheStadium

オリンピックである国のチームが獲得した最高得点を表す変数

maximumNumberOfPointsInModernOlympics

上の変数の特徴

1. 解読しやすい

2. 実用的でないほど長い名前

Javaだとこれくらいの変数名もわりとある

11.1.2 問題指向の名前

覚えやすい良い名前は、一般に、解決策ではなく問題を表現している。良い名前は、方法（how）ではなくもの（what）を表すことが多い。一般に、名前が問題ではなく計算の一部を表すとしたら、それはものではなく方法を表す。そのような名前は避け、問題そのものを表現する問題指向の名前を付けよう。

直感的には出来てるものをテキスト化してくれた感じ。

11.1.3 名前の最適な長さ

変数名は8~20文字のプログラムはある程度デバッグがしやすい。

ただし、これは絶対ではなく短い変数名を見つけたら、変数名の意味が正確かをチェックしようという程度

11.1.4 変数名へのスコープの影響

ローカル変数やループ変数には短い名前が向いてる

iやjなど

グローバル名前空間に属する名前には修飾子をつける

namespaceでグローバル名前空間を分割する

ニーモニック(簡略記号)のプレフィックスをつける

例) db, ui

11.1.5 計算値による変数名の修飾

合計、平均、最大など、計算した値には、Total、Sum、Average、Max、Min、Record、String、Pointerなどの修飾子を名前の最後につける

ただしNumの場合にはインデックスを意味してしまうので要注意

11.1.6 変数名の一般的な反意語

反意語は正しく使う(begin/end, first/last, locked/unlocked)

favoriteの反意語とは…

OSSなら英語として正しいものを

チーム開発ならチームのルールに沿ったものを

11.2 特殊なデータの命名

11.2.1 ループ変数の命名

ループ変数にはi, j, kがよく使われる

ループの外でも使う変数の場合には、より意味のある名前を使う

コピペされることを想定してiなどを使わない人も多いとか

11.2.2 状態変数の命名

flagは使わない

コードの一部を「推理」していることに気付いたら、変数の名前を変更することを検討しよう。推理小説の殺人事件ならまだしも、コードは推理する必要などないはずである。コードは読んで理解できるものにしよう。

11.2.3 一時変数の命名

tmpやa等

一時変数を使うことで重要でないことを明示できる

プログラム変数のほとんどが一時的なものなのでそれを理解せずに使うのはよくない

11.2.4 ブール変数の命名

done/error/found/success/ok

ブール変数には真または偽を意味する名前をつける

errorFileなどは真偽となりえない

is〇〇という命名規則にすることで曖昧な名前を防ぐことができる

if (isFound) は if (found) より読みにくいとのことだがそんなことはない

肯定的なブール変数名を使用する

notFoundなどの二重否定は分かりにくい

11.2.5 列挙型

Color, Month等のグループを示すプレフィックスをつける

列挙型自体を大文字にする

e_のプレフィックスをつける等

列挙型自体がクラスになっているものはColor.RedやMonth.Mayで良さそう

Dartは列挙型自体がクラス

11.2.6 名前付き定数の命名

定数に名前を付けるには、定数が参照する数値ではなく、定数が表す抽象的なエンティティに名前を付ける。

FIVE = 5;

11.3 命名規則の力

標準や規約に反抗するプログラマもいる。それにはもっともな理由がある。柔軟性に乏しく、効果が期待できない標準や規約もあるからだ。それらは創造力を奪い、プログラムの品質を低下させる。

そんなことはない

11.3.1 命名規則を使うべき理由

名前の付け方を考える必要がなくなる

知識をそのまま別のプロジェクトに活かすことができる

新しいプロジェクトのコードをよりすばやく理解できるようになる

名前の増殖を抑えられる

同じ意味の名前の違う変数が多々ある

プログラミング言語の弱点を補う

名前付き定数や列挙型がない変数について、命名規則でどのように扱っているかが分かる

関連する項目同士の関係を明確にする

プレフィックスをつけることでnameがなんのデータなのか分かる

11.3.2 命名規則が必要な状況

大抵の人が必要だよなというとき

複数のプログラマがプロジェクトに従事している

プログラムの変更や保守を別のプログラマに引き継ぐ

プログラムが他の組織のプログラマによってレビューされる

どういう場合だろう？

プログラムが大きすぎて全体を一度に把握することができず、分けて考える必要がある

プログラムの開発期間が長くPENDの時期がある

プロジェクトのあちこちに見慣れない用語があり、コーディングに使用する標準的な用語もしくは省略形がほしい

11.3.3 どのくらい正式なものにするか

プロジェクトによって異なる。大規模なプロジェクトや運用に重きのあるプロジェクトでは正式な命名規則が不可欠である ロリポップとかすごそう

11.4 略式の命名規則

変数名とルーチン名を区別する

本では小文字始まりと大文字始まりで区別

ルーチン名が動詞始まりが一般的と思っていた…

C++由来とのこと

クラスとオブジェクトを区別する

型の先頭の大文字で区別する

型はすべて大文字にして区別する

型に「t_」というプレフィックスを付けて区別する

変数に「a」というプレフィックスを付けて区別する

変数に具体的な名前をつけて区別する 本ではこの方式を採用

グローバル変数を識別する

「g_」というプレフィックスをつける

言語毎にグローバル変数の仕様があるはずだからそれを使うのも良さそう

メンバ変数を識別する

「m_」というプレフィックスをつける

型の定義を区別する

名前付き定数を識別する

列挙型の要素を識別する

入力専用の引数を識別する

名前を呼びやすくする

11.4.2 言語固有の命名規則のガイドライン

PHPならPSRかな

本で紹介しているのはCとC++、Javaの例

11.4.3 混合言語環境でのプログラミングの注意点

どういうパターンだろうか

アプリならネイティブプラグインを実装するときとか？

11.4.3 命名規則の例

CとC++、JavaとVisual Basicの例なので割愛

11.5 標準のプレフィックス

11.5.1 UDT（ユーザー定義型）の省略形

システムハンガリアン

ハンガリアン記法、と言われるとこっちを指すことが多いらしい

11.5.2 意味を表すプレフィックス

アプリケーションハンガリアン

limitとmaxとlastの違いとか、first⇔last、min⇔max

ハンガリアン記法の悪役感がすごい

https://gyazo.com/7170e1f0a4372e5b5fc5b8bac93d562d

11.5.3 プレフィックスの利点

名前を覚える量が減る

max, limit, last などの違いを明確に区別できる

名前が短くなる

型がわかりやすくなる

正直、型がわかりやすくなる以外は、うーんという感じ。

11.6 短くて読みやすい名前の作成

省略形のガイドラインや注意事項などの話

現代の言語では、名前の長さにほとんど制限がないので、意味のある名前をわざわざ短くする必要はない。

そもそも本書でもこう言われているので、短くすることがありきではない

意味がまず大事と考えると、この節で紹介されているルールで、そもそも使えそうなのは限られるなと思った

11.6.1 省略形全般のガイドライン

省略形全般のガイドラインより以下一部のみ抜粋

and, or, theなどの冠詞を削除する

変数名だけじゃなくてコミットメッセージも

日本語でも新聞の見出しは文法的にはおかしかったりする

名前の中で重要な単語を最大で3つ使用する

無駄なサフィックス（ing, edなど）を削除する

意味が逆になったりすることもあるので付けたほうが良さそう

変数名の長さが8~20文字になるまで繰り返す

変数名の長さの目安は8~20文字が目安っぽい

単語が3つくらいあると15文字前後にはなるイメージだから、ofとかforとかを含む変数名だと意外と短く感じるかも

11.6.2 音に基づく省略形

例としてこんな省略形が紹介されている

ILV2KS8

XMEQWK

S2DTM80

NXTC

TRMN8R　ターミネーター？？

11.6.3 省略形の注意事項

だいたいは当たり前だなーという感じ

コードの変換表を用意して、極めて短い名前を文書化する

プロジェクトレベルの「省略形標準」にすべての省略形をまとめる

プレフィックス使うためにここまでやるなら、メリデメ考えるとメリット少ないな

書き手の便宜と読み手の便宜のどちらを優先するのか、という問題を示している。

名前はコードの書き手ではなく読み手にとって重要なものである。

だから初見でわからないくらいならプレフィックス使わない、というのが結局いいよね、となりそう

11.7 避けるべき名前

だいたいは、そうですよねーという感じのことが書かれている。

同じような発音の名前を使わない

これはあまり意識したことなかったけどたしかになと思った

名前の綴りを故意に変えない

故意に変えたわけじゃないけど、一回間違うとIDEで補完されるので間違った名前が使い回されているのを見た

複数の自然言語を組み合わせない

標準ライブラリの型、変数、ルーチンの名前は使わない

変数が表すものと全く無関係な名前を使わない

このあたりの例はひどい…

命名全般の検討事項、命名規則などは割愛

つづり間違いがそのまま利用されいてる例:

コードレビューもJetBrainsのIDEでやるとスペルチェックできる

11.8 まとめ

- コードは書くことよりも読むことのほうがずっと多い。名前をつける際には、書き手の便宜ではなく読み手の便宜を優先すること。

これにつきる

ループ変数や状態変数といった特殊な変数には特に注意

名前はできるだけ具体的に。一般的な名前は通常は悪い名前である

命名規則でデータの種類（クラスデータやローカルデータなど）や型なども区別する

プログラムのサイズやプロジェクトに応じて、変数の命名規則を採用すること

省略形を使うなら、（プレフィックスの辞書に記載するか、）標準化されたプレフィックスを使う